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1. ORGANISATIONAL SET-UP 


In Activity 3 the functional design of the use case Optimising Network Traffic Flow has been described 
and was approved by the SOCRATES?° Steering Group in October 2018. In Activity 4, during the 
preparation phase, this functional design was translated into detailed designs. 


To ensure a proper execution, for the pilot site Amsterdam an Activity Management Team (AMT) was 
installed. This team consisted of the following officers: 


Pilot Site Lead: Giovanni Huisken 

Business manager: Jan Maarten van den Berg 
Alignement manager: Arthur Rietkerk 

Project assurance: Gerben Kiffen 

ICT liaison: Harry van Ooststroom 
Communication officer: Esther de Graaf 

Use Case ONTF lead: Giovanni Huisken 

Use Case SD lead: Marc Rood 

Use Case RW lead: Ruud van den Dries 

Use Case EZ lead: Jan Maarten van den Berg 
Optionally - Project manager: Tiffany Viemmings 


The AMT was active during preparation and execution of the pilot and met approximately 60 times to 
discuss necessary actions, take decisions and guide the development and execution of the Use 
Cases, including communication internally and externally and align with PMT. 


Additional team meetings that took place during development and execution of the use cases at the 
Amsterdam pilot site: 


Pilot Site team meetings: all participating partners represented, bi-weekly meetings 

Develop & Operation team: focus team for ICT developments, bi-weekly meetings 
NL-Preparation team: representatives of all Road Authorities, meetings every 3 weeks 
SOCRATES?° Operational team: representatives of the three TMC’s, irregular ad-hoc meetings 


1.1 Planning (phases) 
It was decided that all four Use Cases were to be divided into three phases: 


1. Development, Plateau 0 phase 
2. Operational, Plateau | phase 
3. Operational, Plateau Il phase 


The development phase would roughly take place from end of Activity 3 until November 2019. Then 
the operational first Plateau would take place from December 2019 — March 2020, while Plateau II 
would be in operation from April 2020 — June 2020. Details are described in chapters 2 -- 13. 
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2. INTRODUCTION - ONTF 


In Activity 3 the functional design of the use case Optimising Network Traffic Flow has been described 
and approved by the SOCRATES?° Steering Group in October 2018. In Activity 4 this functional design 
is elaborated in multiple more detailed designs. Based on this latter design the pilot is developed. 


2.1 Use Case description 


The SOCRATES?! ONTF use case describes how to Optimize Network Traffic Flow in the Amsterdam 
area. 
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FIGURE 1. SOCRATES2° NETWORK 
Figure 1 shows the road network forming the scope of the SOCRATES?° project. 


The network consists of a combination of National roads (A-roads), provincial roads (N-roads) and 
municipal roads (S-roads). 


The network is divided in several links. A link is a one-directional connection between two decisions 
point. On a decision point the driver does make a choice about the next link in their route. 


For each link, volume and speed is monitored. Production is defined as Volume X Speed. When 
volume increases, the production increases as well. However, when there’s too much traffic, the 
speed will drop and therefore the production will no longer grow as expected, and finally it will fall due 
to a traffic jam. By monitoring volume and speed, it is possible to detect when volume starts to slow 
down compared to expected values, resulting in a ‘problem state’. This the trigger to start network 
management activities. See Figure 2. 


The required production for a network link is described as Key Performance Indicator (KPI). When the 
production starts to deviate from the required KPI this will result in problem state can occur. 
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FIGURE 2. TRAFFIC PRODUCTION ON A LINK 


Note: Figure 2 above suggests that traffic is managed when the current state deviates too much 
from the historic state. The suggestion is made to manage traffic also with regular states, e.g. 
send message to Service Providers when daily traffic jams start and traffic still can be 
rerouted. 


To manage the traffic in the SOCRATES? area, information is exchanged between the different sub- 
systems in the area, see the sequence diagram Figure as taken from the Information Architecture 
[IA]. 


2.2 Functional overview (SOLL Act.a vs. IST Start Act.4 vs. 
IST End Act.4) 


Changes in relation to Activity 3 — functional design 
Activity 3: Part 3: SOCRATES*° services for PS-UC 








SOLL Act.3 IST Start Act.4 
System overview with key Data fusion & completion one Limited data fusion and 
functions of the key Network Monitor completion. 

functions. 


Active services private service 


providers feedback to Network Ne leeds Es DOP TOI paaie 


services to Network Monitor. 

















Monitor. 
Only public active services in 
current state. 
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Current active public and 
private services used in 
prediction and current state. 


Common goals (meaning 
public and private goals 
aligned). 


‘Virtual reward’ system for all 
partners impact (public, private 
and intermediary). 


Automated services selection 
by Network Manager. 


Only public goals. 


Reward system is part of 
service for road users only. 


Limited automated Network 
Manager (e.g. more toolbox 
configuration). 





Cooperation models 


Cooperation Model 6 with all 
intermediaries acting ona 
tactical level. 


Cooperation Model 6, where 
intermediaries act, 
intermediaries act on a 
tactical/operational level. 





Roles 


No changes in required roles. 





Intermediary 


No changes in required 
intermediaries. 





Actors 


Not disclosed. 





Pre-/post conditions 


Conditions still apply. 








Sequence diagram 








No significant changes. 





Staged deployment of functionalities 


The operational stage (Dec 19 to June ’20) is divided in 2 plateaus. 


e The 1* plateau is the period from December 2019 until end March 2020. 
o 1st week of November: ‘Company users’ test 


o 24 and 39 week of November: ‘Friendly users’ test 


o 4 week of November (until end of June) and later: ‘SOCRATES?! users’ recruitment 


e The 2" plateau is the period from end March 2020 until end June 2020. New functionalities are 


added in plateau 2. 


Plateau 1 functionalities: 


e Fusion of data from NDW and one Service Provider to describe the current traffic on the 


ONTF network 


e Tilted table from Network Monitor to Network Manager, containing: 
o Current speed and current volume per SOCRATES?” link on the ONTF network 
o Predicted speed and predicted volume per SOCRATES?" link on the ONTF network 
o Activated traffic management measures 
e Distribution of Avoid Service Requests by the Network Manager to the Service Providers 


(in DATEX-II format) 


e Distribution of Avoid Service Requests by the Network Manager to the TMCs (in DVM-X 


format) 


Plateau 2 functionalities: 


e Fusion of data from NDW and more than one Service Provider to describe the current 
traffic on the ONTF network 
e Tilted table from Network Monitor to Network Manager, containing: 
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o Current speed and current volume per SOCRATES?” link on the ONTF network 
o Predicted speed and predicted volume per SOCRATES?” link on the ONTF network 
o Activated traffic management measures 

e Distribution of Avoid Service Requests by the Network Manager to the Service Providers 
(in DATEX-II format) 

e Distribution of Avoid Service Requests by the Network Manager to the TMCs (in DVM-X 
format) 

e Distribution of Reroute Service Requests by the Network Manager to the Service 
Providers (in DATEX-II format) 

e Distribution of Reroute Service Requests by the Network Manager to the TMCs (in DVM-X 
format) 

e Implementation of a Reward system. 


Actual situation End of Operational period (IST End Act.4) 


During the operational period, development did not stop. Almost all items in the total information chain 
underwent changes, notably the Network Monitor (changes of current traffic and prediction), Network 
Manager (steadily improving the functionality to generate appropriate Service Requests) and some 
back-end and end-user services from the Service Providers. 


2.3 Active partners 


Eleven SOCRATES?” partners are active in the Optimising Network Traffic Flow use case Amsterdam. 


BMW Service provider (active involvement limited to chain testing) 
City of Amsterdam Road Authority 
Province of North-Holland Road Authority 
Rijkswaterstaat Road Authority / Network Manager 
NDW Data provider / Network Monitor / Strategy Table organiser 
HERE Data provider 
MAPtm Strategy Table organiser / Assessor 
BrandMKRS End user Service provider 
Be-Mobile Data provider / End user Service provider 
TomTom Data provider / End user Service provider 
Technolution Network Manager 
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3. INFORMATION ARCHITECTURE - ONTF 


3.1 Sequence diagram 


The information architecture (IA) is an elaboration of the sequence diagram originally produced for 
Activity 3. It contains processes (green) and interactions (red) between processes. The processes are 
functional and in general conducted by one stakeholder as an internal process. A process receives 
and collects data, enriches the data and produces information as a product. Information is sent via 
protocols to other processes in the architecture. 


The functional process starts with step 1 (data and measures) and continues all the way to step 17 
(accept / decline (DATEX-Il), see figure 3). 


63 Current traffic state 
(volume, speed & active services} 


16. Define predicted problam state. f- E- = 
harmonisation of servioss | 1 11 Oparator monitoring 
and confict resolution Le 


12 service Request TMC (DVM-X) 
TI 13 Activation of 
+ rosdsiós measures 
(scenario’s) 


TI 16 activation ot 
e In@vidual routing 
+ into 





FIGURE 3. SEQUENCE DIAGRAM ONTF AMSTERDAM. 


Note: the service requests 12 and 15 within figure 3 to TMCs and SPs are drawn sequentially here, 
however, they will be sent out in parallel. 
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3.2 Processes and interactions 


Step 1: Data and Measures (NDW) 
Data elements 


Private and public data providers send actual data and measures to the network monitor (NDW). The 
collection of data and measures consists of multiple data streams from multiple partners: 
a. Traffic data of road authorities (speed and traffic volume on a minute base) — 


most already available at NDW, so NDW will provide this data stream. Open action: volume data 
from city of Amsterdam + Provence, NDW to discuss with City and Provence 
Traffic data of data providers (traffic soeed on a minute base) 


c. Infrastructure capacity status (temporary capacity changes), delivered by road authority and 
status of peak and regular lanes - open/closed) — most already available at NDW, so NDW will 
provide this data stream 

d Incident’ data of road authorities (reports of accidents, incidents and other events (air pollution 
status). This info is essential to determine the cause of a service request. 

e. Status and incident data of data providers (reports of accidents, incidents and other events) 

f. Active traffic management measures from road authorities (e.g. VMS recommendation, ramp 
metering active). Start with rerouting services. This includes activated traffic management 
measures as a result of the service request of the Network manager. 


Decision: Activated strategic routing services from service providers are too difficult to obtain. One of 
the reasons is that the amount of active service provider users is low. 


Networks and links (NDW+RWS) 
= The Monitoring Network is the road network that needs to be used for the collecting of data (all 
black, blue, red and green parts). This is also the network for prediction. 
= The Optimization Network is the road network that needs to be optimized by the network manager 
(all blue, red and green parts). 
= The Network monitor will aggregate data from different data providers to link level. These include: 
speed, volume, services and incident data. 
= Additional effort is needed to aggregate the road authorities’ measures/scenario’s (operational 
level) to services on links (tactical level). 
"ະ A “link” is part of the Network between 2 important decision points for road users. 
= For each coloured part in the network detailed excel files are available for link information. 
o The red network (RWS) has 50 links. 
o The green network (Amsterdam) has 30 links. 
o The blue network (Province NH and UT) has 10 links. 
= Note that a green dot indicates additional data requirements for the UC smart destination. (further 
action is needed to identify the details). 


Step 2: Fusion and completion (NDW) 


The Network monitor needs to know what the traffic state is on the network and what measures are 
activated to influence that traffic state. If necessary, the Network monitor fuses all data from both 
public and private partners. 


Fuse or not to fuse: that’s the question: 
e Fusion (and, if necessary, completion) of traffic speed data from public and private partners. 





1 Incident can be any type of disruption 
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e No fusion of volume data necessary, because there is only data from public partners. 

e Fusion of status and incident data. Reports of incidents and other events from public and 
private partners. 

e No fusion of status information of peak and regular lanes, because there are only data from 
public partners. 


As part of the fusion there will be a quality check and validation on the data. 


Step 3: Current traffic state (NDW) 


Current traffic state is created by NDW. With a 1-minute interval the Network monitor creates a current 
traffic state and sends this to the Network manager. In this stage the current traffic state is a data 
stream, only recognisable by systems. 


The use of a tilted data table. Instead of separate data streams, there is a data stream in which for 
each link in the network, the current state on traffic flow, status information and services is provided. 


The predictions will not be based on the common current traffic state, but on each company’s own 
data and/or own data suppliers. 


Evaluation question: what is the specific value of the current state, is its used for service requests or is 
the prediction only sufficient? 


Decision: The current traffic state is not needed for service providers. The reason being that service 
providers receive a data rich service request via DATEX-II from the Network manager (see TMEx 
profile documents for strategic routing). So, service providers will not use this information. 


The current traffic state is needed for in TMCs as context information because the service request via 
DVM-Exchange only contains an ID of the service. So, more context information is needed. See step 7 
for “who uses what”. 


Difference between DATEX II and DVM-X service requests 



































TMC SP 
Hello Establish communication | DVM-Exchange DATEX II (tmp/cis) 
and recognition 
What Problem Context & pre agreed DATEX II (tmp/cis) 
Where | Location Pre agreed DATEX II (tmp/cis) 
Why Reason Context & pre agreed DATEX II (tmp/cis) 
How Avoid/strength/incentive Pre agreed DATEX II (tmp/cis) 
When Timing ? DATEX II (tmp/cis) 








Step 4: Predicted traffic states from TTM, BML and NDW/PTV (NDW) 


At the moment there are three partners (NDW, TomTom and Be-Mobile) who are interested in 
providing a “prediction engine”. The predictor calculates the prediction of the traffic state based on 
current data and advanced prediction techniques. 


It is assumed that the prediction engines use own data together with (fused) data from NDW. 


The prediction function should be able to plug into the Network monitor base system; there is no direct 
connection between the predictor engine and the Network manager. 


The prediction engines can run simultaneously for the whole period. 
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The predicted traffic state is calculated every 5 minutes with a default horizon of 15 minutes. The 15- 
minute value is about the speed and volume. 


TomTom and Be-Mobile predictions are not using active road side services. 


The PTV prediction currently only use the lane status from highways (MSI). PTV will also use the road 
side inflow/outflow services. 


Step 5: Prediction processing (NDW) 
NDW receives the predictions from 3 partners. 


The Network monitor selects 1 of the 3 predictions for the Network manager. It is decided that here will 
be 3 consecutives periods of 2 months, starting 1* of September. After that 3 consecutives periods of 
1 month will follow. This gives the prediction partners the possibility to improve functionality in the 
second half of the operational period. 


Map matching needs to be done in order to feed the network managers Network. 


And NDW will send the predicted states to the Network manager. 


Step 6: Predicted traffic state (NDW) 


With a 4-minute interval the Network monitor creates a predicted traffic state and sends this to the 
Network manager. This is the primary process. 


Decision: The predicted traffic state is not needed for service providers. The reason being that service 
providers receive a data rich service request via DATEX-II from the Network manager (see TMex 
profile documents for strategic routing). So, service providers will not use this data. However, service 
providers get access to MobiMaestro-web. This enables the service provider to view the context 
information. 


The predicted traffic state is needed for in TMCs as context information because the service request 
via DVM-Exchange only contains an ID of the service. So, more context information is needed. See 
step 7 for who uses what? 


Step 7: Use of the current, predicted and problem state (TMCs) 


TMCs are users of the “current, predicted and problem state”. TMCs need this information to optimise 
their process in combination with service requests. TMCs tend to visualize this in order to give the 
traffic operators a continuously update and context information to interpret ‘service requests’. 


Delivery options: 
a. Mobi-Maestro web viewer as a separate screen 
b. Integrate Mobi-Maestro solution, no separate screen needed. 


TMC-RWS and TMC AMS wishes to use the integrated MobiMaestro solution, no separate screen 
needed. 
TMC-PNH: wishes to use the MobiMaestro web viewer as a Separate screen. 


However, all TMCs have accepted the integrated MobiMaestro solution as the best workable solution. 


Step 8: Define predicted problem state (TEC / RWS) 


The network manager defines the predicted problem state based on the predicted traffic state and the 
KPIs. The Network manager monitors the KPIs continuously. 


The aim is to optimize the network traffic in the region of Amsterdam. The road network in this area 
consist of a combination of national roads, provincial roads and municipal roads. This road network is 
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monitored continuously and when deviations occur the SOCRATES?! Network manager will start a 
network optimization effort in order to optimize the traffic flow and minimize traffic jams. 


This is done in a couple of steps: 
e The road network is divided in 114 links. 
e For the links in the network the productivity is determined. Productivity is defined as ‘speed x 
volume’ per link. This is done for every 5 mins. 
e When the measured actual productivity is deviating too much from the historical pattern, this is 
a trigger for the SOCRATES?! network manager to evaluate alternative services. 


This is described in more detail in the following paragraphs. 


Step 9: Problem state context information (TEC / RWS) 
This is about the service request context information. 


The Network manager creates a current, predicted and problem state for the Network manager 
operators (TMC-RWS). 


The current state is provided real time (every minute) while the predicted and problem state is 
provided every five minutes. These products are (in the 5-minute cycle) synchronised so that they are 
based on the same timestamp. 


Step 10: Harmonisation of services, impact calculation and conflict resolving (TEC / RWS) 


The network manager creates or chooses the most effective set of services to solve or ease the 

problem state of the entire network. 

= The network manager can choose from multiple services from the pre-defined toolbox by the 
Strategy Table. 

= 2 types of routing services are identified: 

- 1) “avoid link A” > SP/TMC decide how to reroute away from link A. 
- 2) “avoid route A and reroute traffic via alternative routes B and C” 

« ` Inflow and outflow service requests are out of scope for SPs. 

= ` Inflow and outflow requests could be sent to TMCs. TMC Amsterdam and TMC NH have got a lot 
of means to activate an inflow/outflow requests. 

= Services are pre-agreed “measures” from service providers and traffic management centres. 

= The impact is an estimated parameter for every service. On a monthly basis, traffic engineers 
monitor and if needed adjust the impact parameters to align them with the “truth”. This “truth” is 
based on the assessor’s report and expert judgement of the RA engineers/rKCO. Further 
elaborating of the impact is needed. 

= (fa service request is sent to service providers, all service providers will receive the same service 
request. 

= Multiple services are combined without internal conflicts. However, it is possible that “instrument” 
conflicts happen on operational level in the TMC. The traffic operator should prioritise in this case. 

«The aim is to make this step fully automated with limited operator intervention. 


Toolbox 


Strategy table and Network manager have discussed current toolbox and implementation in the 
Network Manager (MobiMaestro). 
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Toolbox 























Available Services 
Links (mei |TMC2 |TMC3 | SP1 SP2 SP3 SP4 
1 S1,2 55 56 57 58 
51 55 56 57 58 
53 55 56 57 58 
54 55 56 57 58 
114 55 56 57 58 
































The practical implementation of toolbox in MobiMaestro has been implemented by Rijkswaterstaat. 


Step 11: Operator monitoring (RWS) 


This data stream is visualised by MobiMaestro for TMC-RWS because the problem state is needed to 
understand why service requests are received. The NDW viewer will not be used within SOCRATES?°. 


Just monitoring by operator. Logging of issues. 
Same as step 7 for TMC RWS. 


Step 12: Service request and step 14 - accept/decline (TEC/RWS) 


The network manager sends services requests to traffic management centres. 
= A service request can be accepted or declined by the receiving partner. 
«Only accepted services requests are used for impact validation by the assessor. 
= Service requests to TMC use the DVM-X protocol. 
"Service request information elements are: 

- Message ID (‘volgnummer’) 

- Toolbox service ID 


Step 13: Activation of roadside measures - scenario’s (TMCs) 
Internal process traffic management centre. 
All requests to TMC are send via DVM-Exchange. 


Translation of service request to response plan configuration in MobiMaestro has been taken into 
account by adjusting existing response plans. 


Step 14: Accept / decline (DVM-X) (TMCs) 


The TMC either accepts or declines the request. 


Step 15: service requests to SP and step 17 accept/decline (TEC/RWS/NDW/SPs) 


The network manager sends services requests to service providers and traffic management centres. 
= A service request can be accepted or declined by the receiving partner. 

«Only accepted services requests are used for impact validation by the assessor. 

= Service requests to SP use the DATEX II tmp/cis protocol. 
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= Service request information elements are: 
- Message ID (‘serial number’) 
- Location reference of effected link (where is the problem) 
- Direction of the link (e.g. eastbound, westbound, ...) 
- Strength of the requested service: weak, medium or strong (default medium) 
- Location reference of alternative routes 
- Reason of SR: Incident classification (e.g. accident, debris, weather, roadworks, event, 
. ..) 
- duration of incident on that location 
- Time: start-time & expected end-time of request 


Step 16: Service activation Service Providers (SP) 
Service activation by service providers is done automaticly. 


Service providers will balance common and individual preferences before advising customers to follow 
the strategic route requested by the Network manager. 


Step 17: Accept / decline (DATEX-II) (SP) 


The SP either accepts or declines the request. 
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4. SYSTEM ARCHITECTURE - ONTF 


4.1 System / Application overview 


(Data) Providers Network Mgr Service Provider / TMC 


R BeMobile Apps etc. 
pen 
Data BeMobile 


(NDW) TomTom 





BMW Apps etc. | 


TomTom Apps etc. | 


data BrandMKRS Apps etc. | 
sources 





data 


sources Facman 






MM 
| Prov NH 


Assessor 


data 
sources 











Assessor 


FIGURE 4. SYSTEM OVERVIEW ONTF AMSTERDAM 


System Overview —— Socrates interface ——» Internal interface 


SOCRATES?" consists of five main components (figure 4): 

- (Data) providers: traffic information is gathered in different ways and by different entities: NDW 
gathers traffic intensity and speed information from loops, service providers do gather speed 
information from e.g. FCD. NDW provides the gathered information as ‘open data’ to 
providers. 

From this information the (data) providers compute an actual and predicted traffic state. 
The TMCs provide information about the current outstanding measures. 
NDW matches all provided data to their own map. 

- The Network monitor gathers all actual and predicted traffic states and transmits it to the 
SOCRATES?° Network manager. 

- The SOCRATES?° network manager evaluates the current and predicted traffic states. It 
compares the situation with the KPls as stored in the KPl-table. If the current and / or 
prediction deviates too much from the KPI value, measures must be taken in an effort to keep 
the traffic production at the required KPI level. 


Note: actual criteria for maximum deviation are under discussion. 

All possible measures and their expected impact on traffic production are stored in the Toolbox. 
The SOCRATES?° network manager uses a network optimizing algorithm that calculates all 
combinations of possible traffic measures as offered through the toolbox in order to find the optimal 
solution. The network manager translates this solution in one or more service requests that results 
in rerouting, limit input, promote output. These are sent to the involved TMCs and to the SPs. 

A TMC can respond that a requested service is accepted, rejected, or that it is already enabled. 
Based on this feedback the network manager can further optimize the network. 

- The TMCs and SPs receive service requests. E.g. enable access dosing on a highway access 


point for a TMC or avoid A9 for a service provider. 
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- The assessor component receives all relevant information and monitors the effectiveness of 
SOCRATES?° measures for both TMCs and SPs. The assessor does not do that real time, but 
once per month. 


The interfaces are described in more detail in the next paragraphs. 


4.2 Overview interfaces 


An overview of the identified interfaces is shown in the application architecture. Dotted lines represent 
manual processes, full lines represent automated processes (figure 5). 





(Data) Providers Network Mgr Service Provider / TMC 


e 6 
Data BeMobile 
TomTom 
(OWE 9,15,17 


data BrandMKRS Apps etc. 
sources 







BeMobile Apps etc. 





BMW Apps etc. 








TomTom Apps etc. 


data 


sources Facman 


MM 
data ] Prov NH 


sources (2) 





Assessor | 


Assessor 


Communication Interfaces C socrates interface (2) Internal interface Releated interaction from seguence diagram 








FIGURE 5. APPLICATION OVERVIEW WITH INTERFACED IDENTIFIED ONTF AMSTERDAM 








Interface 1 - Open data to Data providers 








MessagelD 11.0A 
Message: Speed/volume 
Protocol: Providers: proprietary 
NDW to data providers: DATEX-II 
Frequency: Every minute 


Related sequence message ID: None 
Related TMEX dataset: None 


Message information 




















Field Remark 
Data Date & time stamp 
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Volume Number of vehicles per link 
Speed Average speed 
Travel time Derived from average speed 





Infrastructure status 


On the selected link // to be provided by NDW 





Event data TMC 


Event information as provided by Road Authorities 




















Interface 2 -Data Source to Data providers 











Interface 2 is a proprietary interface from Data source to Data provider, used internally by the Data 
provider. It is not described here. 





Interface 3 - Data provider to Network monitor 











Message ID 
Message: 


Protocol: 


Frequency: 


13.01,04 
13.01: Actual traffic state, 
13.04: Predicted traffic state 


Messages are identical, only a flag indicates if data is actual or 
predicted. 


Choice of data provider 


The actual state is given every minute. The prediction is given every 
five minutes. 


Related sequence message ID: 01, 04 
Related TMEX dataset: Speed & flow data 


Incidents 


Message information 




















Field Remark 

Data Date & time stamp 

LinkID ID of the data provider network link for which the traffic state is given 
Travel time Average travel time per link 

Volume Optional: Number of vehicles per link 

IsPrediction TRUE= Predicted state, FALSE=Actual traffic state 





PredicitionTime 








If message is a Prediction, this fields shows for which time the Prediction is 
made. 
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Interface 4 - Network monitor to Network manager 








MessagelD: 14.03,06 

Message: 14.03 Actual traffic state 
14.06 Predicted traffic state 

Protocol: DATEX-II 

Frequency: The actual state is given every minute. The prediction is given every 
five minutes. 


Related sequence message ID: 3, 6 
Related TMEX dataset: None 


The Network monitor does receive the Actual traffic states and the predicted traffic states. Possibly it 
also has an own actual and predicted traffic state. From the available states, the Network monitor 
sends one actual state per minute to the Network manager. From the available prediction states, one 
is sent to the Network manager every five minutes. 


- Current Speed 
- Current Flow 
- Incidents (in eerste instantie van wegbeheerders; later mogelijk ‘crowd sourced’) 
- Activated measures: 
- DVM services by TMC's (via DVM Exchange) 
- Images message signs (MSI's) - red cross, falling arrow, speed limit 
- Prediction of Speed (15-minutes horizon) 
- Prediction of Flow (15-minutes horizon) 
- Speed Reference 
- Flow Reference 





Interface 5 - Network manager to Scenario evaluation 











Interface is declared obsolete within the current scope of the project. 





Interface 6 - Network manager to TMCs 











MessagelD: 16.09 

Message: Problem state viewer 
Protocol: DVM-X 

Frequency: 2 minutes 


Related sequence message ID: 09 
Related TMEX dataset: None 


Message information 





Field Remark 
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MessagelD: 
Message: 
Protocol: 


Frequency: 


16.12 
Service Request 
DVM-X 


When necessary, a couple of times per day, estimation: max 10 / day. 


Related sequence message ID: 12 
Related TMEX dataset: None 


Message information 



































Field Remark 
ID Service Request ID 
ReqService ID of requested service 
Strength Weak, medium, strong 
AlternativeRoute | Location alternative route (OpenLR) 
Reason E.g. accident, debris, weather, roadworks, event 
StartTime 
EndTime 
MessagelD: 16.14 
Message: Service Request Response 
Protocol: DVM-X 
Frequency: After sending 16.2. 


Related sequence message ID: 14 
Related TMEX dataset: None 


Message information 


























Field Remark 
ID Service Request ID for which response is given. 
Response Response to the request. Possible values: 
- Accepted 
- Rejected 
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Interface 7 - Network manager to Service Providers 








MessagelD: 

Message: 

Protocol: 

Frequency: 

Related sequence message ID: 
Related TMEX dataset: 


17.09 

Problem state 

DATEX-II (with translator to MDM for Munich) 
when requested 

9 


Strategic Routes 


** All Service Providers receive the same Service Request. 


Avoid link + alternative route(s) 


Message information 




















Field Remark 
MessagelD: 17.15 
Message: Service Request 
Protocol: Datex-ll 
Frequency: Whenever necessary, a couple of times / day. 


Related sequence message ID: 
Related TMEX dataset: 


Message information 


15 
TMPlan exchange 





























Field Remark 
ID Service Request ID 
ReqService Requested service. 
StartTime Start time of the requested service 
EndTime Expected end time of the requested service 
MessagelD: 17.17 
Message: Service Request Response 
Protocol: Datex-ll 
Freguency: 1x After Service Reguest 


Related seguence message ID: 
Related TMEX dataset: 
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Message information 
Field Remark 








ID Service Reguest ID for which response is given 
Response Response to the request. Possible values: 
- Accepted 


- Rejected 























Interface 8 - TMCs to NDW 











MessagelD 18.01 

Message: Active measures messages 
Protocol: DVM-Exchange 

Frequency: On occurrence 


Related sequence message ID: 01 








Related TMEX dataset: None 
Field Remark 
Link ID of SOCRATES?" link 


Is ‘Link’ enough detail? (e.g. One link can contain a section with and without 
‘spitsstrook’, or multiple drips 





ActiveMeasureTMC | Description of active measure 














ActiveMeasureSP 





FINAL REPORT AMSTERDAM PILOT AND ON 14-6-2021 


EE vaN OPERATIONAL PERIOD 
the European 
Commission 


4.3 Overview Assessor interfaces 


All SOCRATES?” components log their actions and make these actions available to the Assessor. The 
assessor evaluates the actions and how effective they are, see figure 6. 





(Data) Providers Network monitor Network Mgr | Service Provider / TMC | 





Apps etc. 


Open 
Data BeMobile 


Apps etc. 
(NDW) TomTom PP 


Eos TomTom Apps etc. 
BrandMKRS 


Apps etc. 








data 
sources 


> Bea | 


data ` | 


sources 
Strategy 
Table 


Facman 


MM j 
Prov NH 





data 
sources 





Assessor 


Network Assessor connections 
Report?? 


FIGURE 6. OVERVIEW OF ASSESSOR RELATED INTERFACES ONTF AMSTERDAM 


(1) The network monitor stores: 

- Received current states from Data providers 

- Received prediction states from Data Providers 

- Own current & predicted states 

- The Current and predicted state sent to the Network manager 


(2) The network manager stores: 

- Outcome of scenario evaluation 

- Service requests sent to service providers and TMCs 
- Service responses received 


(3) The TMCs store received service requests, and the corresponding response. 


(4) The Service providers store received service requests, and the corresponding response. 
Preferably also if users have followed the advice or not (in aggregated manner). 


(5) The assessor stores the evaluation report of all data. 


All stored data is sent to the Assessor once / week. 


4.4 Interfaces per partner 


The SOCRATES?° partners are responsible for the delivery of different types of data. This corresponds 
to the identified interfaces. This chapter lists the interfaces used by each partner. Each interface has 
two ‘sides’: one side is providing the data, the other side is receiving and consuming the data. 
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The interface numbering of figure 6 is used. 






















































































Be-Mobile 
Supported interfaces 
Interface | Message Role Remark 
M.A Speed/volume | Consumer 
11.B Measures Consumer 
13.01 Actual Traffic | Provider It contains at least the information like described in 
state Interface 3. The format however is proprietary and 
discussed with NDW. 
13.04 Predicted traffic | Provider 
state 
17.09 Problem state Consumer 
17.15 Service request | Consumer 
17.17 SR Response Provider 
Assessor information 
(4) Service requests received and service request response 
BMW 
Supported interfaces 
Interface | Message Role Remark 
M.A Speed/volume | Consumer 
11.B Measures Consumer 
13.01 Actual Traffic | Provider It contains at least the information like described in 
state Interface 3. The format however is proprietary and 
discussed with NDW. 
17.09 Problem state Consumer 
17.15 Service request | Consumer 
17.17 SR Response Provider 
Assessor information 
(4) Service requests received and service request response 
HERE 
Supported interfaces 
Interface | Message Role Remark 
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M.A Speed/volume | Consumer 
11.B Measures Consumer 
13.01 Actual Traffic | Provider It contains at least the information like described in 
state Interface 3. The format however is proprietary and 
discussed with NDW. 
17.15 Service request | Consumer 
17.17 SR Response Provider 
Assessor information 
(4) Service requests received and service request response 
BrandMKRS 
Supported interfaces 
Interface | Message Role Remark 
17.09 Problem state Consumer 
17.15 Service request | Consumer 
NDW 
Supported interfaces 
Interface | Message Role Remark 
M.A Speed/volume | Provider 
11.B Measures Provider 
14.03 Actual Traffic | Provider 
state 
14.06 Predicted traffic | Provider 
state 
Assessor information 


(1) Received Actual and Predicted traffic states 
(1) Actual and Predicted traffic states sent to Network manager 


























PTV 
Supported interfaces 
Interface | Message Role Remark 
13.04 Predicted traffic | Provider 
state 
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Technolution 

























































































Supported interfaces 
Interface | Message Role Remark 
14.03 Actual Traffic | Consumer 
state 
14.06 Predicted traffic | Consumer 
state 
16.09 Problem state Provider 
16.12 Service Provider 
Request 
16.14 SR Response Consumer 
16.14 Problem state Provider 
17.15 Service request | Provider 
17.17 SR Response Consumer 
Assessor information 
(2) Actual and predicted problem states 
(2) Service request sent to TMCs 
(2) Service request sent to Service Providers 
TomTom 
Supported interfaces 
Interface | Message Role Remark 
M.A Speed/volume | Consumer 
|1.8 Measures Consumer 
13.01 Actual Traffic | Provider It contains at least the information like described in 
state Error! Reference source not found.. The format 
however is proprietary and discussed with NDW. 
13.04 Predicted traffic | Provider 
state 
17.09 Problem state Consumer 
17.15 Service request | Consumer 
17.17 SR Response Provider 
Assessor information 
(4) Service requests received and service request response 
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5. INTRODUCTION - SD 


In Activity 3 the functional design of the use case Smart Destination has been described and finalised. 
In Activity 4 this functional design is translated in a technical design. Based on this design the pilot is 
developed. 


5.1 Use case description 
Main problem 


The main problem at events in the Amsterdam Arena area is the sub-optimal traffic in- and outflow 
before and after an event and the sub-optimal parking choice distribution in the area. 


The problems are caused by: 


e Visitors have little knowledge about parking location & occupancy 
e Routing services do not consider parking guidance & occupancy 
e Routing services do not consider recommendations of road authorities to optimize outflow 
e Trip origin is not considered in route recommendation 
Mission 


The mission of the use case is to ensure a satisfactory journey for the event visitors by improving 
traffic flow distribution (in-flow/out-flow) over space and time using optimized dynamic parking during 
event and in the event neighbourhood. 


Sub-missions are: 


e To provide people a satisfactory travel experience to a parking location, in particular better 
information and guidance 


e To improve inflow traffic and parking choice distribution in order to reduce the outflow peak. 


5.2 Functional overview (SOLL Act.3 vs. IST Start Act.4 vs. 
IST End Act.4) 


Changes in relation to Activity 3 — functional design 


Activity 3 Activity 4 
3.1 System overview For SOCRATES?* no data on 


actual traffic state is sent to the 
Network Manager OMC. The 
OMC is an existing role and has 
already sufficient insight in the 
actual traffic state. 

3.2 Cooperation Model Cooperation Model 3 or 5 No changes 

(depending on events with data 
exchange only, or events with 
coordinated services) 

3.3 Roles Because no data on the actual 
traffic state is needed, the data 
provider roles on road data are 
removed. 

3.4 Intermediary There will be no real strategy 
table. The strategy table role is 
embedded in the evaluation 
meeting after an event. 
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3.5 Actors Not disclosed 

3.6 Pre/post-conditions No changes 

3.7 Sequence diagram There will be no exchange of data 
on the actual traffic state or 
historic origin-destination. Also, 
there will be no prediction on the 
parking occupancy. 


Staged deployment of functionalities 


The operational stage (March '20 to July ’20) was divided in 2 plateaus. 


e The 1* plateau was the period from March 2020 until end May 2020. 


e The 2" plateau was the period from June 2020 until end July 2020. New functionalities would 
be added in plateau 2. 


Plateau 1 functionalities: 

e Public and private parking data is sent to Network Manager OMC 

e Data on road closures is sent from OMC to service providers 

e Service requests with the parking status and recommended routes is sent from OMC to 
service providers 

e Inthe end user service, a parking location (location depends on the origin of the user) is 
presented as the destination instead of an event location 

e Inthe end user service, the parking location and/or the route will be changed during the trip, if 
the parking is almost full (information in the service request), if the recommended route is 
changed by the OMC (information in the service request) or if roads are to be avoided due to 
measures implemented by the traffic management centres (in the data on road closures) 

e (option) A map with a walking route to the event location is presented in the end user service 
after parking the car. 


Plateau 2 functionalities: 
e Public and private parking data are fused to a common picture and is sent to the service 
providers 


Actual situation End of Operational period (IST End Act.4) 


Due to the outbreak of the Covid-19, all events in the Netherlands were canceled from March 2020 
onwards. Unfortunately, this meant that the use case could not be put into practice. Only 4 technical 
chain tests and a field test with friendly users could be held. 


The elaboration of the use case has not progressed further than plateau 1. 


During de elaboration of plateau 1, it turned out to be too difficult for to process the recommended 
routes from the service requests. Both parties have indicated that they will adjust the parking 
destinations in response to the information in the service request. Based on their own traveltime data, 
they calculate the fastest route, taking into account any closed roads (as passed on in the data feed 
with road closures), but not using the recommended routes from the service request. 


Because routes from the service request are not used, they are not offered as a service at the outflow. 
For the outflow, the service request only includes a recommended route that cannot be processed. 
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5.3 Active partners 


Eight SOCRATES?” partners are active in the Smart Destination use case Amsterdam. 


Partner Role in use case 


City of Amsterdam Data provider (parking data) / Network Manager / Road Authority 
NDW Network Monitor (only in plateau 2) 
Technical enabler datafeed road closures 
Technolution Technical enabler datafeed service requests 
MAPtm Assessor 
TomTom End user Service provider 
Be-Mobile End user Service provider 
BrandMKRS End user Service provider 
Data provider parking data (only in plateau 2) 
BMW Service provider for user evaluation use case (no end user service) 


5.4 Generic description of end user services 


The service offers road users smart individual route advice to a free parking space. In case of an 
event, when a visitor (and user of the navigation services of the SOCRATES?” partners) asks for a 
route to the Johan Cruijff Arena and/or ZiggoDome and/or AFAS Live Music Hall, he is presented with 
the possibility to choose an parking location as destination instead of the event location itself. The 
parking locations that are presented, depend on the origin of the visitor. In order to spread traffic 
across the area and avoid large flows of crossing traffic, visitors from the East, for example, are guided 
via the A1 and A9 to parking locations in the southeast of the Amsterdam Arena area. The selected 
parking locations are in line with the response plans of the road authorities. 


On the way to the parking location, the route is constantly updated by the service providers, taking into 
account the travel time on the route. 


At the same time, road authorities are monitoring the traffic and parking situation in the Operational 
Mobility Centre (OMC). This OMC fulfils the role of network manager in this SOCRATES?° use case. 
The OMC can decide on traffic measures (implemented by the traffic management centres) and on 
service requests to service providers (with recommendations for routes and parking garages). By 
processing the service request by the service providers, visitors can be offered a different route or 
parking destination in their navigation, so that they always have the fastest route to a free parking 
space. 


Arriving at the destination, the user receives a map with a walking route to the event location 
(optional). 


Key elements of the service are: 
e Pre-trip: Choose a parking location as the destination (instead of an event location) 
e Pre-trip: The parking locations presented depend on the origin of the user 
e Onthe way: change parking location (and possibly route) if the parking location is almost full 
e Onthe way: change route (and possibly parking location) in case of higher travel time 
e Onthe way: change route (and possibly parking location) in case of implemented measures 
by the traffic management centres (road closures) 
e Post-trip optional: A map with a walking route to the event location 
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6. INFORMATION ARCHITECTURE - SD 


6.1 Sequence diagram 
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FIGURE 7. SEQUENCE DIAGRAM SMART DESTINATION AMSTERDAM PLATEAU 1 
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FIGURE 8. SEQUENCE DIAGRAM SMART DESTINATION AMSTERDAM PLATEAU 2 
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6.2 Processes and interactions 


Step 1: Parking Data 


In the ArenA Poort Area there are private and public parking operators. Garages of both operators are 
used for parking during events and therefore parking data of all garages in the area is needed. 


The parking data of the public parking locations are published at the open data portal of the City of 
Amsterdam. Characteristics: 

— every minute 

— availability of free parking places 

— occupancy ratio 

— in- and out movers 

— based on loops and barrier movements 

— SPDP (Standard for Publishing Dynamic Parking Data) 
— JSON 

- DATEXII 

— open data pull (not a pushing platform) 


The parking data of the private parking locations differ per private party. At least the data consists of 
availability and occupancy ratio. 


Step 2: Fusion (only plateau 2) 


The Network monitor combines the parking data of the public and private parking locations into a 
current parking state. 


Step 3a: Current parking state (only plateau 2) 


The current parking state of the parking locations in the area is provided by the Network monitor to the 
Network manager / OMC. The current parking state consist of the actual available capacity per garage 
(amount of free parking places). For viewing the web based MobiMaestro of the TMC Amsterdam is 
used. The parking information is included and processed in the MobiMaestro. 


Step 3b: Current parking state (only plateau 2) 


The current parking state of the parking locations in the area is provided by the Network monitor to the 
service providers. The current parking state consist of the actual available capacity per garage 
(amount of free parking places). 


Step 4: Monitor and manage response plans 


This task will be carried out by the OMC. Based on the traffic and parking situation and the response 
plan, the OMC decides on the measures and recommendations. These measures are requested from 
TMC Amsterdam and the service providers. 


The response plans follow a strategy with prioritization of access routes and parking garages for a 
preferred order in which traffic is led into the area. In order to spread traffic across the area and avoid 
large flows of crossing traffic, visitors from the East, for example, are guided via the A1 and A9 to 
parking locations in the southeast of the Amsterdam Arena area. 


The OMC uses the web-based version of MobiMaestro of the TMC Amsterdam to implement the 
measures. 


Step 5: Request TMC Amsterdam to deploy measures 


Because of the use of the MobiMaestro of the TMC Amsterdam in the OMC, a decision and activation 
of a measure by the OMC automatically results in a deployment of the measures by the TMC 
Amsterdam. 
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Step 6: Road closures 


If the decision of the OMC leads to road closures or forbidden directions, the information about these 
measures is sent to the service providers (in DATEX Il). These measures can be used by service 
providers for their route advice to their users, so the users cannot receive impossible advice through 
closed roads. 


On technical level the information on road closures is sent from the MobiMaesto of Amsterdam to 
NDW, which in turn makes the information available at an end-point from which the service providers 
can extract it. 


Step 7: Service Request 


In its role as network manager, the OMC sends service requests to the service providers. 

The service requests are specific routes from the highway to a free parking garage (or group of 
parking garages). The OMC has insight into the free parking spaces in the event area and will provide 
a route (according to the strategy in the response plan) to those free parking spaces. The service 
request supports the traffic management measures in the area deployed by the TMC. 


If a parking location is almost full, a new service request is sent, with a route to another parking 
location. If a route is too busy or closed (in the case of implemented measures by the traffic 
management centres or an incident), a new service request is also sent. 


The following routes will be used for the service request: 


Al ຫູ N oas A2 and A9 
Big event າງ Big event 








Prio 1: —— route via A9 / 5112 south / 86, 87 y a EA F Prio 1: —— route via 3111 south / P3, P4, PS 
route via A9 / s112 south / P21, P22, P23 Sa Prio 2: - - - route via 5111 south / 86, P7 
route via A9 / 5111 south / 83, P4, PS a Prio 3: ----- route via A9 / 5112 south / P6, P7 
route via A9 / 5111 south / P6, P7 route via A9 / s112 south / P21, P22, P23 
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FIGURE 9. STRATEGY PARKING AND ROUTES SMART DESTINATION AMSTERDAM 


For each direction a separate route is sent as a service reguest; starting with the route with priority 1 in 
the maps above. In case of a full parking location or a busy or closed road, one of the other routes is 
sent as a service reduest. 


For example, the following map shows the routes that are sent as a service reguest at the start of an 
event in the Amsterdam Arena. 


Example 
start situation 
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From Al: route via A9 / 5112 south to 86, 87 
From A2/A9: route via 5111 south to 83, P4, P5 
From A10 south: route via s111 north to P2 

From A10 north: route via s112 north to P21, P22, P23 





FIGURE 10. EXAMPLE PARKING ROUTES AT START EVENT SMART DESTINATION AMSTERDAM 


On technical level the service request is sent from the MobiMaesto of Amsterdam to Technolution, 
which in turn makes the information available at an end-point from which the service providers can 
extract it. 
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Step 8: Service activation 
Internal process of service provider. 
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7. SYSTEM ARCHITECTURE - SD 


7.1 System / application overview 


Parking operators Network Monitor Network Manager TMC Amsterdam Service Providers 
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NDW. 


Tern ni inal f 
OMC 


FIGURE 11. SYSTEM OVERVIEW SMART DESTINATION AMSTERDAM PLATEAU 1 
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FIGURE 12. SYSTEM OVERVIEW SMART DESTINATION AMSTERDAM PLATEAU 2 


7.2 Overview interfaces 


An overview of the identified interfaces is shown in the application architecture. In this picture internal 
(black) and external (purple) interfaces are shown. The internal black interfaces are not described in 
detail. Partners are responsible for own internal interfaces. 


The external purple interfaces are numbered 1 to 7 and are described in the table below. 
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7.3 


ID Partner (system/app) Information Status 
SD AMS 1a Systems Parking Original source for the parking Existing source 
Operators - OMC information Existing interface 
Existing receiver 
SD AMS 1b Systems Parking Original source for the parking Existing source 
(plateau 2) Operators — Parking information New interface 
platform t.b.d. New receiver 
SD AMS 2 Parking platform t.b.d.— (Current parking state in New source 
(plateau 2) Systems service DATEX New interface 
providers New receiver 
SD_ AMS 3 Parking platform t.b.d. —- Current parking state in New source 
(plateau 2) MobiMaestro TMC DATEX New interface 
Amsterdam (OMC) Existing receiver 
SD_ AMS 4 MobiMaestro TMC Road closures in DVM-X Existing source 
Amsterdam — NCIS Existing interface 
NDW Existing receiver 
SD AMS 5 NCIS NDW -- Systems Road closures in DATEX New source 
service providers New interface 
New receiver 
SD_AMS 6 MobiMaestro TMC Request for change of route New source 
Amsterdam — and parking in DVM-X New interface 
MobiMaestro New receiver 
Technolution 
SD AMS 7 MobiMaestro Publication of service requests New source 


Technolution — Systems 
Service Providers 


(parking and route) in DATEX 


Interface 7 description (TMex) 


Functional top-level information-elements inflow 


The provided dynamic information is separated in two functional parts: 


Preferred routes to defined parkings in the Arena area. 


New interface 
New receiver 


preferred routes are independent from the availability of parking places in the parking, but are 
defined to spread traffic from the different directions over the available network in the area, 
minimising the chances of junction-locks. 

The preferred route to a parking can change due to traffic conditions. 

preferred routes are provided, depending on the origin (defined by the rerouting decision point 
(RDP)) and destination (the preferred parking from that origin at a specific moment in time (based 
on availability)). 

The functional expectation is that those vehicles on their way to the indicated destination, which 
have not yet passed the RDP are guided in their navigation via the provided preferred route. There 
is no expectation about marking the RDP with an icon. 

This activation applies only to those vehicles that have not yet passed the decision point at the 
moment of activation. All vehicles between the decision point and the destination (the original 
parking) will normally have access to the original parking and can continue their journey as 
planned. 

The preferred routes are not necessarily the shortest or the fastest route to the parking. 


Unavailable parkings 


unavailability can be because the parking is full, or because it cannot be reached due to an 
incident on the route towards the parking. When a parking becomes unavailable a recommended 
alternative parking is provided. 

It can happen that different alternatives are provided, depending on the origin of traffic. 
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e With this the navigation devices can determine whether his destination is still available or he has 
to switch to the recommended alternative. 


Functional top-level information-elements outflow 


Once the event comes to an end, the mandatory outflow routes are published. These service requests 
provide information about original routes that are not available (closed) and a mandatory alternative 
that needs to be followed until the end of the provided alternative. From here on the navigation can 
determine the route to the destination of the end user. 


Corresponding DATEX II messages 


This information is provided in DATEX II situations, with the following functional breakdown in 
situations and subsequent situation records. 


— (Inflow service request) For each origin of traffic a Situation with ID SOCO02 PSAxx (with x being 
the roadnumber + E or S in case of the A10) for the status of the parkings from that origin. These 
situations are having: 

o One situation record per unavailable parking and its current alternative. The alternative 
record also holds the origin of traffic. 
o A record is published, once the parking unavailability demands for it. 
o If an alternative gets full: 
= An additional record stating the unavailability of this parking is published (in 
combination with its alternative) 
= the record of the already full parking(s) is updated with the new alternative. 


— (Inflow service request) Per origin a situation with ID Soc02 X (where X is determined by the road 
name of the decision point where the preferred route to the Arena area starts. So for the A2 X=2, 
For the A9 X=9 etc.) 

o per route-destination combination a rerouting situation record is maintained, providing the 
decision point of the alternative route and the destination. 

= The preferred route is provided as alternativeRoutelnformation giving the 
preferred route to get to the destination, starting at the decision point, 

= The decision point is the location of the situationRecord which is of type 
ReroutingManagement. The destination is in the destination. 

= The complianceOption is set to mandatory, as in this service, it is agreed that the 
service will comply and not assess himself alternatives. 

"ະ It is not a binding traffic regulation, that would only hold if a competent authority 
mandates a detour or deviation by an official regulation, which is not the case 
here. 

o A changing destination because of unavailability of the parking, will result in 

= suspending of the situation record with the active routing 

= activating the situation record with the preferred route to the new destination. The 
new record will have a cause, which refers to the relevant Parking unavailability 
records in situation SOC02_0. 


— Once the traffic and parking situation allows for it: 
o preferred routing situation records will be ended. 


— (Outflow service request) Per Parking a situation with ID Soc02 Pxyz (where xyz is determined by 
the numbers of the parking to which the service request applies. 

o a rerouting situation record is maintained, providing the decision point for the alternative 
route. This is by default the exit of the Parking. 

o The originalRoutelnformation provides the stretch of road which is not available. If the 
navigation would normally have routed via this originalRoutelnformaiton, it now shall adapt 
the route to the one provided in alternativeRoutelnformation. 

o The preferred route is provided as alternativeRoutelnformation giving the preferred route 
to leave the parking. 
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o The navigation is supposed to follow the entire alternativeRoute and determine the final 
route to the destination of the traveller from the last point of the alternative route onwards. 

o The decision point is the location of the situationRecord which is of type 
ReroutingManagement. 

o The complianceOption is set to mandatory, as in this service, it is agreed that the service 
will comply and not assess himself alternatives. 

o Itis a binding traffic regulation, because a competent authority mandates the detour by an 
official regulation, supported with authorised traffic controllers. 

o The outflow route can change. In that case an update of the involved situationrecord with 
the modified alternativeRoute and, if applicable the closed originalroute will be published. 


— Once the traffic and parking situation allows for it: 
o parking unavailability records will be ended 


DATEX II exchange 


The provided information is snapshot push. Which means that only records and situations that have 
been modified are sent. The client needs to maintain the complete overview of the parking status and 
service requests based on the received information. The server does not offer automated 
resynchronisation services. 


The ending of situationrecords and situations can therefore be recognised by the fact that they are not 
in the published d2Payload message anymore. 


The last message is an empty d2Payload. 


Example 
16 December 2019: 


e 20:00 Event in the Johan Cruyff Arena starts. 
e 22:00 Event ends. 


This timeline is about the provided information for traffic coming from the south of Amsterdam via the 
A2. For the other origins (A1, A9, A10 south and A10 east) the same information is provided 
simultaneously. 


The priority in parkings and routes for the origin A2 is as follows: 


t ເ ເ ເ 
isterdam isterdam 'sterdam 
d Course d m d Course ah vn d Course 





1. P3, P4, P5 via s111 2. P6, P7 via s111 3. P6, P7 via s112 4. P21, P22 via s112 
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The corresponding DATEX II publications are: 


16:00: 
18:14: 
18:53: 
19:47: 
20:15: 
21:30: 
22:38: 
23:53: 


SOCO02 2 1 (A2_Prio1_via_s111_to 





SOCO02 2 2 (A2 Prio2 via 5111 to 


P6 P7) 





SOCO02 2 3 (42 Prio3 via s112 to 


P6 P7) 





SOCO02 2 4 (A2 Prod via s112 to 





SOCO02 2 EndOtfPreferredRouting 
SOCO02 P345 1 (Outflow P3 P4 P5 via BSW. to A2) 
SOCO02 P345 2 (Outflow P3 P4 P5 via s111 to A9) 
SOC02 TerminationOfAll 


Parking P3, P4, P5 
85% full 


P21_P22) 


P3_P4_P5) 








P3, P4, P5 
unavailable, 
alternative P6, P7 


SOC02_PSA2 


16:00 | Start of Smart | Preferred route to P3, | SOC02 2 SOC02 2 1 1 
Destination Plan P4, P5 activated 


SOC02_PSA2_1 





Preferred route to Pa, 
P4, P5 suspended 


SOC02_2 


SOC02_2_1 





Route 


to parking 
P6, P7 via s111 
blocked 


Preferred route to P6, 
P7 via s111 activated 


P3, P4, P5 
unavailable, 
alternative P6, P7 


SOC02_PSA2 


SOC02_2 2 


SOC02_PSA2_1 





Preferred route to P3, 
P4, P5 suspended 


SOC02_2 


SOC02_2_1 





Preferred route to P6, 
P7 via s111 
suspended 


SOC02_2 2 





Preferred route to P6, 
P7 via 5112 activated 


SOCO2 2 3 





























19:47 | Parking P6, P7 85% | P3, P4, P5 | SOCO2 PSA2 | SOCO02 PSA?2 1 
full unavailable, 
alternative P21, P22 
P6, P7 unavailable, SOCO02 PSA2 2 | 1 
alternative P21, P22 
Preferred route to P3, | SOCO2 2 SOC02_ 2 1 
P4, P5 suspended 
Preferred route to P6, SOC02 2 2 
P7 via s111 
suspended 
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Preferred route to P6, 
P7 via s112 
suspended 


SOC02_2 3 





Event is underway 
All preferred routes 
are withdrawn 


Preferred route ໄດ 
P21, P22 activated 


P3, P4, P5 
unavailable, 
alternative P21, P22 


SOC02_PSA2 


SOC02_2 4 


SOC02_PSA2_1 








The outflow 
strategy starts 


Route P3, P4, P5 
towards A2 blocked 


All situations are 
ended 





P6, P7 unavailable, 
alternative P21, P22 


P3, P4, P5 are 
directed towards the 
A2 


P3, P4, P5 traffic is 
directed towards the 
A9 


Empty D2Payload 





SOC02_P345 


SOC02_P345 
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8. INTRODUCTION - RW 


In Activity 3 the functional design of the use case Road Works has been described and finalized. In 
Activity 4 this functional design is translated in a technical design. Based on this design the pilot is 
developed. 


In this report the technical design is described. After the description of the use case and information 
architecture, the technical architecture identifies the different system components and describes the 
interfaces between these components. 


8.1 Use case description 


The use case Road Works focusses on data quality improvement in the live stream as described and 
finalised in activity 3 for Road Works use cases. The use case was to be deployed in the following 
pilot sites; 


e Antwerp 
e Amsterdam 
e = Munich 


The use case description for all Pilot sites is the same and incorporates a pilot site specific roles, 
datafeeds and extensions. 


The pilot site Amsterdam planned to include a contractor. The partnered Contractor has a (external) 
contract during the pilot period to perform scheduled and ad-hoc maintenance work within the pilot 
region. The contractor would share planned and changed road works information in a real-time form 
with the Intermediair as do the Service Providers and Road Authorities. The contractor would rely his 
planning information and any updates to the network monitor and in return will receive a full common 
operational picture for road works. 


The pilot site Amsterdam involves three Road Authorities, namely; 


e City of Amsterdam 
e Province of North-Holland 
e Rijkswaterstaat 


These RA's are mainly represented and facilitated by NDW. 


In all pilot sites the assessor will investigate the quality improvement and establish the value of the full 
chain and aid in deriving win-win-win’s from the lessons learned. 


Because of the fact that the 100% RW use case for pilot site Antwerp was already 80% for the 
Amsterdam and Munich sites, it has been decided to combine the RW use cases for all sites into one 
effort and resulting document with extensions for Amsterdam and Munich. 


8.2 Functional overview (SOLL Act.3 vs. IST Start Act.4 vs. 
IST End Act.4) 


Changes in relation to Activity 3 — functional design 
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Activity 3 Activity 4 


3.1 System overview Fusion result distributed as DATEXII not implemented in end 
TMeX and JSON result data feed 

3.2 Cooperation Model Shared view No changes 

3.3 Roles Road Authority, Agregator Public The role of Contractor has not 
Data provider, Private Service been fulfilled 
provider, Network Monitor, 
Contractor 

3.4 Intermediary MAPtm fulfils the role of No changes 
intermediary and Tursted Third 
Party 

3.5 Actors MAPtm, NDW, HERE, TomTom, No contractor 
Be-mobile, PNH, contractor 

3.6 Pre/post-conditions Supplied current data sources No “deltas” nor quality inidicators 
will not be provided as-is for use provided with common picture 
within this use case feed 

3.7 Sequence diagram No significant changes 


Staged deployment of functionalities 


The operational stage (December '19 to June ’20) is divided in 2 plateaus. 


e The 1* plateau is the period from December 2019 until end March 2020. 


e The 2% plateau is the period from April 2020 until end June 2020. New functionalities are 
added in plateau 2. 


Plateau 1 functionalities: 


This plateau featue a first version of data fusion focussing on simple fusioning the data from all 
sources into a common view where overlapping/same reports are merged into one report. 


Plateau 2 functionalities: 


Built upon plateau 1, this release encompasis als the interpretation by the intermediary based on the 
provided data on the subjects of probability, thustwurthiness and detail completeness. All engulving 
from a successful fusion process, established in plateau 1. 


Actual situation End of Operational period (IST End Act.4) 


The aimed result from Plateau 1 has been delivered as planned but as a two stage rollout. First rollout 
saw the incorporation of the data from the private partners. This data has been fetched, stored, 
combined and slimmed to create a fused set. Incorporation of the data from the Road Authorities had 
more technical challenge than expected based on the supplied and known characteristics of the data. 
The sheer amount of data available combined with the characteristics of the data format used for 
suppling the data has proven difficult to handle. This was overcome by upgrading the available 
hardware specification on the supplier side and spending more time than planned on implementing the 
data. 


Due to these setbacks, and every pilot site having setbacks (similar or different) the allotted time for 
realising the set goals within the use case has proven not to be sufficient. 
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This has been mitigated by focussing on delivering plateau 1. Main reason for this has been that the 
results of fusion and the match-rate achieved with fusion between sources had not a high rate. 
Creating the common view including delta's and probality rates would be possible but without a 
significant number of matches to test and affirm the working of the developed fusion methode. 


What has been developed is a proposal for changing/extending DATEX-II with a extra 
container/element that ensures the insights from the intermediary on delta’s, matchrates, data 
extending, data inserting and probility rates can be included and communicated using the DATEX-II 
framework. 
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9. INFORMATION ARCHITECTURE - RW 


9.1 Sequence diagram 


Roadworks Amsterdam Sequence Diagram 
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FIGURE 13: SEQUENCE DIAGRAM ROAD WORKS AMSTERDAM 


9.2 Partners and User Stories 


User stories focus on the experience — what the Actors using the product want to be able to do. User 
stories should be written in one or two sentences and capture who the user is, what they want, and 
why. 


A simple structure for defining features or user stories can look something like this: As a , | want 
to achieve so that | realize the following benefit of : 


User stories are used to describe the information architecture in a logic and seguential way. The 
information architecture (IA) is a textual elaboration of the sequence diagram. It contains 

e Actors — entity that is capable of performing behaviour (e.g. companies, institutions). 

e Roles — responsibility for performing specific behaviour, to which an actor can be assigned, or 
the part an actor plays in a particular action or event. 
Services - explicitly defined exposed behaviour 
Processes - sequence of behaviours that achieves a specific outcome. 
Events - behaviour element that denotes a state change 
Interfaces - A point of access where one or more services are exposed to the environment. 
Objects - element (often information or data object) that cannot perform behaviour. 
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User story from TMC perspectives 


Road Operators 


Road Authority: Rijkswaterstaat, Province of Noord-Holland and NDW 


As a Road Authority, | want to provide actual hindrance of roadworks to the road user. 


I collect roadworks information from various data sources. This is an existing service, 
nothing new needs to be developed for SOCRATES?°. 

The information is provided via NDW to a public endpoint. The data is provided in DATEX 
II format to the intermediary. The message includes information about start time and end 
time of the roadworks as well as the location of the roadworks. The message can, 
depending on the local situation, contain additional information on lanes closed/available, 
roads closed, narrowed lanes, lane diversion, temporary traffic lights, mobile road works, 
hindrance class, limitations for vehicles with certain characteristics, residual road width, 
speed restriction, road availability for emergency services during roadworks, rerouting and 
overrunning 

I monitor the network and validate the roadworks information and if possible update the 
information based on a constant monitoring and measure setting process. This is an 
existing service, nothing new needs to be developed for SOCRATES*°. 

| detect new roadworks or changes in the existing ones. This is an existing service, 
nothing new needs to be developed for SOCRATES”. Based on this | provide updated 
information to the public endpoint. 

NDW receives a common roadworks picture from the intermediary in DATEXII format. 
This message includes information about the roadworks (location, time and 
extend/length), the Universal Unique ID for the roadworks, and a confidence level. 

| use the common roadwork picture received by though the intermediary to evaluate the 
quality of own road works information and aim to improve the process for generating Road 
Works information. 


Identified Interface 1: DATEX II (based on v2.3) between Road Authority — Intermediary (From RA 
to Intermediary only) 


າມີແ OPERATIONAL PERIOD 
the European 
Commission 


Objects exchanged: Either the “wegwerkzaamheden” feed of NDW or the “actuele 
statusberichten” feed of NDW. 

The “wegwerkzaamheden” feed is both planned and actual Roadworks. The two types 
can be distinguished by status. The “actuele statusberichten” feed contains all current 
situational messages active on the road, including actual roadworks which can be 
distinguished if wanted. 


Situation record creation time 

Situation record version 

Situation record version time 
Probability of occurrence 

Validity status 

Overall start date 

Overall end date 

Period start date (if applicable) 

Period end date (if applicable) 

location by coordinates 

location by Linear Referencing (if available) 
Network Management type (+ subtype) 
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lanes closed/available 

mobile road works if applicable 

roads closed if applicable 

narrow lanes if applicable 

temporary traffic lights if applicable 

lane diversion if applicable 

hindrance class 

limitations for vehicles with certain characteristics 
residual road width if applicable 

speed restriction if applicable 

road availability for emergency services during roadworks 
rerouting 

overrunning if applicable 


Identified Interface 2: DATEX II (based on v2.3) between Intermediary - Road Authority (From 
Intermediary to RA only) 


Objects exchanged: 


Location OpenLR 

Location as WGS84 

Start datetime for RW 

End datetime for RW 

UUID (for when only a delta is provided from Network Monitor) 
Situational record version 

Probability of occurrence (confidentiality) 

Validity status 

Type of Roadworks 


User story from SP perspectives 


Be-Mobile 


Service provider: Be-Mobile 


As a Service provider, | want to provide most accurate real time information on roadworks to my 
users, so that they experience a satisfying journey. 
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I collect roadworks information from various data sources. This is an existing service, 
nothing new needs to be developed for SOCRATES?°. 

| monitor the network and validate the roadworks information based on additional data 
sources. This is an existing service, nothing new needs to be developed for SOCRATES?°. 
| detect new roadworks or changes in the existing ones. This is an existing service, 
nothing new needs to be developed for SOCRATES?°. 

Roadworks information are part of the incident feed that we provide to our customers 
through an API. The data is provided in JSON format to the intermediary. The message 
includes information about start time and end time of the measure as well as the location 
of the roadworks 

| receive a common roadworks picture from the intermediary in DATEXII format. This 
message includes information about the roadworks, the trackable ID for the roadworks, 
and a confidence level. 
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| validate internally against my information the common roadwork picture and, if 
necessary, update my information and/or algorithms. 


Identified Interface: JSON between Be-Mobile — Intermediary 
Objects exchanged: 


TomTom 


Author (Be-Mobile) 

Country (Belgium, Netherlands) 

Event_ID 

Source (Flemish TMC, TouringMobilis, Waze, Police, ...) & source_ID 
Version (new version when features of traffic event change, e.g. extra lane closed). 
Alert C code (description of traffic event) 

Freetext (textual description of traffic event) 

Heading (direction of traffic event) 

Location TMC 

Location Wgs84 

Location Wkt 

Location Geojson 

Starttime (YYMMDDHHMMSSZ (UTC)) 

Endtime (YYMMDDHHMMSSZ (UTC)) 


Service provider: TomTom 


As a Service provider, | want to provide most accurate real time information on roadworks to my 
users, so that they experience a satisfying journey. 


I collect roadworks information from various data sources. This is an existing service, 
nothing new needs to be developed for SOCRATES?°. 

I monitor the network and validate the roadworks information based on additional data 
sources. This is an existing service, nothing new needs to be developed for SOCRATES*°. 
| detect new roadworks or changes in the existing ones. This is an existing service, 
nothing new needs to be developed for SOCRATES?°. 

Roadworks information are part of the incident feed that we provide to our customers 
through an API. The data is provided in DATEXII format to the intermediary. The message 
includes information about start time and end time of the measure as well as the location 
of the roadworks 

| receive a common roadworks picture from the intermediary in DATEXII format. This 
message includes information about the roadworks, the trackable ID for the roadworks, 
and a confidence level. 

| validate internally against my information the common roadwork picture and if necessary 
update my information and/or algorithms. 


Identified Interface: JSON between TomTom- Intermediary 
Objects exchanged: 
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Situational record creation time 

Situational record version 

Situational record first supplier version time 
Probability of occurrence 

Validity status 
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e Overall start date 
e location OpenLR or WGS84 
e Network Management type 


User story from Intermediary perspectives 


Network Monitor 


Intermediary: MAPtm 


As an Intermediary, | want to provide most accurate real time information on roadworks to the 
Service providers and road authorities by fusing their data, so that they can provide the most 
accurate data to their end systems. 


I collect roadworks information from various parties. This is an existing service for road 
authorities, and a new service for Service Providers. 

| monitor the data and fuse data where needed and/or extend the data sets. 

I detect newly reported Road Works and add them to the data set with a new UUID. 
Based on input from service providers | add a probability for the Road Works information. 
| produce a Common Road Works Picture which is provided to Service Providers and 
Road Authorities and the Assessor. 


Identified Interface: TMeX between Intermediary - Use Case partners 
Format of interface supplied is either JSON or XML. By choice of partners 
Objects exchanged: 


e Location of event (openLR & WGS84) 

Unique Event_ID 

Version (new version when features of traffic event change, e.g. extra lane closed). 
description of traffic event 

Freetext (textual description of traffic event) 
Heading (direction of traffic event) 

Location Wgs84 

Starttime (YYMMDDHHMMSSZ (UTC)) 
Endtime (YYMMDDHHMMSSZ (UTC)) 
Probability 

Number of sources reporting event 

Detection method (Manual, System, User Input) 
Quality Index 


Assessor 


Intermediary: MAPtm 


The assessor shall determine the rate of quality improvement based on the delivered data per SP 
and RA and the fused result. Assessment shall be done based on data completeness, timeliness 
and probability rate. For this the user feedback loop will be used where possible. 
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10. SYSTEM ARGHITEGTURE - RW 


10.1 System overview 





Loop 


HERE Improvement 
Be-Mobile 





City of 
Amsterdam 


Network Monitor 


Province of 





Amsterdam Antwerp Munich 





Rijkswaterstaat 





Common Data 
Feed 





FIGURE 14: SYSTEM OVERVIEW ROADWORKS AMSTERDAM 


10.2 Interface descriptions 
Interface ALLSITES-RW-CM3: 

Information can be pulled 

Objects to be included (technical description): 


INT2 type definition requirement comment 


Scope name 
[Space Jiocetion Opent x k foenn TI 
POINT(x,v.2) REES Optional 

versioning 


DATETIME EE 





























is e 
| 
versioning is needed 


copy from date? 
Situational record first supplier 
ie PP H copy from daten 
version time 
! certain/probable/riskOf 
Probability of occurrence already available ein/probalile/ - 
certain is definitief (change van starttime) 


Lo Frye of Roadworks 


lanes closed/available 
[| O e 


Reduced speed 


lone lane traffic control 
Counterflow traffic 


Detour information 











>Groupoflocation boom 
of 
> impact 


> OperatorActions - 
optional k 
RoadorCarriageWaytManagement 


Do we need this? Can we get this 
from a different daten container for | SpeedManagement 
this location? 
Temporary Traffic Light Signals GeneralNetworkManagement > 
TEXT or INT EE EE TLC for controlling one lane traffic ae 
in use or Traffic Warden trafficManuallyDirectedBy 
Traffic is divert to the other side : 
TEXT or INT alternating traffic over one lane 
of the road 


; aE ReRouting Management (in NL verplicht 
Copy from input. Avaliable in , 
A om andere route op te geven als gebruikt 
antwerp/munich? 
wordt) 
RoadOrCarriageManagement > 
. useOfSpecifiedLanesAllowed 
Passable for emercency services 
(wegafgesloten voor alles behalve) 
(validity aangeven met period) 


0 = open, 1 = closed, sequence 
number for lane postition on road 



















Changed Traffic Situation x ? Road Layout has changed for changes in longer term RW 
dependable on whether this is 
Author x TEKST or INT Alert created by Giewel Source 
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name INT2 





type definition 


requirement [comment 









location OpentR lopenLR 


Need Optional 





location WGS84 ix 
ational record creationtime fxd 


POINT(x,y,2) 








versioning 


DATETIME 








Situational record version 
Network Management type 


Situational record first supplier 
version time 


Probability of occurrence 


UUID 
Type of Roadworks 




















Optional Optional 


copy from datexil? 





copy from date? 


certain/probable/riskOf 


already available 
Y certain is definitief (change van starttime) 


Traceability 








UUID Unigue ID 
TEXT or INT moving, stationary, long-term 


lanes closed/available TEXT or INT status of lane availability 






>Groupoflocation boom 
of 
> impact 


0 = open, 1 = closed, sequence 
number for lane postition on road 








Narrow Lanes TEXT or INT 





lanes wit reduced width 


> OperatorActions - 


optional 
id RoadorCarriageWaytManagement 










Reduced speed 


Do we need this? Can we get this 
from a different datexil container for 
this location? 


SpeedManagement 









Temporary Traffic Light Signals 
in use or Traffic Warden 





one lane traffic control TEXT or INT 


GeneralNetworkManagement > 


TLC for controlli lane traff 
or controlling one ane Watic _|trafficManuallyDirectedBy 








Traffic is divert to the other side 
of the road 





Counterflow traffic TEXT or INT 


alternating traffic over one lane 










Detour information 


ReRoutingManagement (in NL verplicht 
om andere route op te geven als gebruikt 
wordt) 


Copy from input. Avaliable in 
antwerp/munich? 









Passable for emercency services 


RoadOrCarriageManagement > 
useOfSpecifiedLanesAllowed 
(wegafgesloten voor alles behalve) 
(validity aangeven met period) 








(Changed Traffic Situation 


Road Layout has changed 


TEKST or INT Alert created by 





10.3 RW Message sample 
Road Works endpoints 


for changes in longer term RW 








dependable on whether this is 


Source 
allowed 


For all pilot sites (Amsterdam, Antwerp, Munich) the Road Works URL-endpoints are formatted in a 


unified structure; 


httops/roadworks.maptm.nl/fpilotsiteViresponseformad/ 


The variables within the URL are: 


PILOTSITE: This can either be; Amsterdam, Antwerp, Munich 
RESPONSEFORMAT: This can either be; TMEX or JSON. 


TMEX (XML for DATEXII v2.3) 


No valid example available at time of writing. 


Road Works data identified in the fusion process to not be within the provided RA DATEX-II feed will 
be injected into the existing and supplied DATEX-I feed and rebroadcasted with an extra container for 
added information from the SOCRATES?” project. Original and updated/added information will co-exist 


in this feed. 


JSON Format 
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"520 tmexid": 136514, 

"520 creationtime": “2019-12-17118 : 302" , 
"520 updatetime": “2019-12-17118 :307" , 
"5209 endtime": null, 

"520 version": 1, 


"520 isactual": true, 


"roadname": "Camera Obscuralaan", 
"“locationdescription": "Camera Obscuralaan", 
"directiondiscription": "Construction work:Camera Obscuralaan, between 


nsterstraat and Oranjebaan", 


"impactdelay": null, 


"location wgs84": "LINESTRING(4.87716 52.303272,4.876755 52.302063)", 


"location fordisplay": "POINT(4.87716 52.303272)", 
"alertccountrycode": null, 

"alertctableid": null, 
"alertcttrafficcodee": null, 
“alertcdescriptione": null, 
"alertcduratione": null, 
"alertcdirectione": null, 
"alertcttrafficcode1": null, 
“alertcdescriptioni": null, 
"alertcdurationi": null, 
"alertcdirection1": null, 

"“planned startdatetime rw: "2@19-12-17T18:14Z", 
"actual startdatetime rw: null, 
"“detected_datetime_rw": null, 
"situationalrecordversion": null, 
“generalnetworkmanagementtype": null, 
"“situationalrecordfirstsuppliertime": null, 
“number. ofoccurences": null, 

"probability ofoccurences": "Probable ", 
“probability rate": null, 

“type ofroadworks": "CONSTRUCTION", 
"numberoflanesrestricted": null, 
"numberofoperationallanes": null, 
“originalnumberoflanes": null, 


"roadclosed": false, 
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"“temporaryspeedlimit": null, 
"onelanetrafficcontrol": null, 
"counterflowtraffic": null, 
"detourinformation": null, 
"passableforemercencyservices": null, 
"changedtrafficsituation": null, 


"author": "Socrates 


10.4 Processing the data 


Every data feed of the partners was aligned with dataset (TMex) for the Road Works that was agreed 
upon and where useful information was added if one of the partners data feed had specific useful 
information. Table 1 shows the contents of the RW-TMex message. As the table shows the list of 
fields is rather straight forward without nesting information in (sub)containers. Many data fields are 
already available in varying degrees within the data feeds provided as sources for this use case. 


TABLE 1 TMEX MESSAGE SET 





Response field 


definition 


Comment 


s20_tmexid VARCHAR Socrates 20 uuid 
ສກ : ວ Within 
s20_creationtime Integer First creation time GEGEE 
3 : ງ Within 
s20_updatetime timestamp Last update time framework 
s20_endtime WEES Detected end time ດ 
framework 
F timestamp 4 Within 
520 version Version of message າວຫ 
520 isactual boolean Message is current 
roadname VARCHAR Streetname 
locationdescription VARCHAR descriptive ວ, for 
location information 
directiondiscription VARCHAR orientation of RW 
impactdelay Integer Time lost due to RW SNE 
- location OpenLR openLR 
location_wgs84 location WGS84 Linestring 
location_fordisplay location for display (WGS84) POINT 
alertccountrycode from alertC when available VARCHAR 
alertctableid from alertC when available Integer 
alertcttrafficcode0 from alertC when available Integer 
alertcdescription0 from alertC when available VARCHAR 
alertcduration0 from alertC when available VARCHAR 
alertcdirectionO from alertC when available VARCHAR 
alertcttrafficcode1 from alertC when available Integer 
alertcdescription1 from alertC when available VARCHAR 
alertcduration1 from alertC when available VARCHAR 
alertcdirection1 from alertC when available VARCHAR 
planned startdatetime rw Planned Start datetime RW timestamp Start time of Road works 
actual startdatetime rw Actual start datetime RW timestamp Reported Start time 
detected datetime rw Detected datetime RW timestamp This is NOT a start time 
situationalrecordversion Situational record version Integer 
EEU ESME IERE N Network Management type VARCHAR 


nttype 
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situationalrecordfirstsuppl 
iertime 

number ofoccurences 
probability ofoccurences 


probability rate 


type ofroadworks 
numberoflanesrestricted 
numberofoperationallanes 


originalnumberoflanes 


not available currently, 
planned for future 
incorporation 


roadclosed 
temporaryspeedlimit 


onelanetrafficcontrol 


counterflowtraffic 


detourinformation 
passableforemercencyser 
vices 


changedtrafficsituation 
author 


Data harmonisation 


Situational record first 
supplier version time 
Number of data suppliers 
reporting the same RW 


Probability of occurrence 
Probability rate 


Type of Roadworks 


lanes closed/available 
Number lanes opened for 
traffic during RW 

Number of lanes opened for 
traffic during normal 
operation 


Narrow Lanes 


Reduced speed 


one lane traffic control 


Counterflow traffic 


Detour information 
Passable for emercency 
services 


Changed Traffic Situation 
Author 


VARCHAR 
Integer 
VARCHAR 
REAL 


VARCHAR 
Integer 
Integer 


Integer 


TEXT or INT 
boolean 
Integer 
boolean 
boolean 


VARCHAR 
boolean 


VARCHAR 
VARCHAR 


Number of sources 
reporting some RW 

rate for RW are to be 
seen on the road 

rate for trueness of RW 
info 

moving, stationary, long- 
term 

status of lane availability 
Number of lanes 
available 

Number of lanes 
available in normal 
situation 


lanes wit reduced width 


Road closed due to road 
works 


Temporary Traffic Light 
Signals in use or 
Traffic Warden 

Traffic is divert to the 
other side of the road 


Road Layout has 
changed 
Alert created by 


When available 
When available 


During the matching stage of de data feeds of the partners towards the TMex message set, it was 
striking how much the shape and the contents differed per feed, provider and even between sites( e.g 
DATEX-Il). So, for every feed for every site the code to retrieve and convert to the SOCRATES?° 
dataset (TMex) was rewritten and adapted. Feeds differ in complexity, from a compact and 
straightforward dataset with actual road works to complex DATEX-II data sets including not only actual 
roadworks but also planned or even past events. Moreover, the naming and coding (e.g. containers or 
not) of the fields differs per feed. This is also regarding TMC and DATEX-II standardised fields as well. 


Differences in georeferencing 
e TMC is not harmonic over all sites. The implementation of the TMC principle divers per 


site/country and thus has had its particularities per site. 


e Documentation for TMC is only available for paying members of TISA. Beyond that a current 
TMC table must be retrieved from the relevant governing bodies and isn’t available as open 
data everywhere. Though, payment is never required for obtaining the TMC tables. 

e Service Providers use different geospatial projections. But in most cases provided alternative 
projections within the feed. 

e The Flanders data feed is provided with only TMC as geospatial reference. 

e Relying solely on TMC geospatial referencing limits the area where RW can be reported as 
TMC is not covering all roads (e.g. local and residential roads). This difference is especially 


visible between Public and Private sources. 


Differences in data provision 
e DATEX-II has proven not harmonic over all sites 
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e Detail information is not consistent added 

e Update intervals are not always clear and never in sync. 

e DATEX-II feed from NDW was to large for a stable feed. To get a good performance Extra 
RAM memory was allocated on the NDW side and we used a cut out from the region of 
Amsterdam. 


10.5 Common roadworks picture 


Timing information 


The timing information differs between the data feeds. Some providers broadcast roadworks which are 
actual. But NDW for instance broadcasts, running and planned. One source gives status actual and 
end time. 


MDM broadcasts multiple datetime fields. To see if a roadwork is actual the fields startofperiod and 
endofperiod were used. 


Geospatial information 


All the feeds define a startpoint/location for display. Some combine this with a line string (for instance 
MDM) and/or an endpoint. TMC gives start- and endpoint, no line string but offset distances to be 
calculated based on a map matching procedure and requires knowledge of the used TMC 
implementation and possession of the relevant TMC tables. Same goes for NDW and one of the 
private providers. 


When looking at the TMC point information, some points where not available in the basis information 
of the TMC points table. This is probably due to having possession of TMC3.1 while the broadcasted 
information is version 3.3. 


Having said that, a known issue when plotting data to any map is the differences between maps, 
differences between how geo information is written down (X/Y, TMC, Alert-C, VILD) and differences in 
how geo information is projected on a map altogether. Differences in projection occur due to the fact 
that the earth is a sphere and it is near impossible to correctly plot any point on that sphere on a flat 
representation of the sphere. The most common projection is the Mercator projection, invented by 
Flemish cartographer and geographer, Gerardus Mercator. As an example Flemish point data has 
been provided in a different project within this project. Just indicating how divers this data spectrum 
can be. Figure 5 illustrates this. 
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FIGURE 15: AN INCOMPLETE LIST OF TYPES OF MAP PROJECTIONS 


For this purpose, all provided geo data had to be translated to a common projection in order to be able 
to find matches I. 


For a first analyses the startpoint/location for display was used for geographical referencing. 
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11. INTRODUCTION - EZ 


In Activity 3 the functional design of the use case Environmental Zone has been described and 
approved by the SOCRATES?° Steering Group in October 2018. In Activity 4 this functional design is 
elaborated in multiple more detailed designs. Based on this latter design the pilot is developed. 


11.1 Use Case description 


Prohibited vehicles 


Trucks (vehicle category N2 and N3) that have a diesel engine and are heavier than 3.500 kg and 
have a euro 3 norm or lower. This means trucks with euro 0, 1, 2 or 3 diesel engines are not allowed. 
Some special vehicles (like vehicles for exceptional transport, crane trucks, concrete mixers / concrete 
mixers and fire engines) are allowed if they not older than 13 years. Buses and coaches, with the 
exception of scheduled bus services, are also prohibited in the environmental zone. 


Static and dynamic Environmental Zone 


The static Environmental Zone is shown on the map below. Around 60 days per year trucks and 
others are allowed in a part of the environmental zone (via the Kennedylaan), because the standard 
route is not suitable at that moment. This is because of severe traffic delays towards and from the 
highway and/or a high amount of trucks during the start and end of events in the RAI area. In most 
cases the dynamic exemptions duration is several days. This is due to building up events in the RAI 
venue. In other cases the duration is 1 to 2 hours due to severe congestion. 


Alternative 
route 


- Standard 
-p route 
| 


Amsterdam 


Rijkenuseum @ 
Vandelpark 





FIGURE 16. GEOGRAPHICAL OVERVIEW ENVIRONMENTAL ZONE AMSTERDAM 


Problem to solve in this use case 


Many road users don’t know there is an environmental zone before they see a sign. Or they don’t 
know in advance that their route is through an environmental zone. In addition, it is not clear to 
everyone what requirements apply and whether their vehicle can enter the zone. With the result: 
vehicles with Dutch number plates are fined, which leads to unhappy travellers and vehicles with non- 
Dutch number plates are not recognized and not fined, which leads to unfair penalizing and ignoring of 
the environmental zone. 
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For the dynamic zone the communication about the availability of the route is complicated; not for 
everyone this prism sign is clear. This leads to little use of the road, which does not help to reduce the 
delay on the standard route. 


Use case mission 
The mission of the use case is to provide better information for truck and coach drivers. 


e Static information about the existence and limitations of the environmental zone and; 
e Dynamic information about the status of the dynamic zone (on or off). 


By means of execution and validation of this use case, it contributes to the overall goals of 
SOCRATES?*: 


e Testing of public private cooperation and new business models; 
e Testing of effectiveness of Traffic Management 2.0 — sharing of data) 


11.2 Functional overview (SOLL Act.3 vs. IST Start Act.4 vs. 
IST End Act.4) 


Changes in relation to Activity 3 — functional design 
Activity 3: Part 3: SOCRATES?! services for PS-UC 


Activity 3 Activity 4 


3.1 System overview No changes 


3.2 Cooperation Model ‘Data exchange’ It's a simple ‘Shared view’, because 
there is a central trusted intermediary 
Network Monitor. However, for this use 
case data is gathered from only 1 data 
provider (Amsterdam). Furthermore, 
there is no Assessor. Change is only 


semantic. 

3.3 Roles No changes 
3.4 Intermediary No changes 
3.5 Actors Be-Mobile, TomTom, Not disclosed 

BMW and HERE are 

service providers. 

Municipality of 

Amsterdam is data 

supplier. 
3.6 Pre/post-conditions No Changes 
3.7 Sequence diagram No Changes 
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Staged deployment of functionalities 


The operational stage (Sept 19 to June ’20) is divided in 2 plateaus. 


e The 1* plateau is the period from September 2019 until end January 2020. 
o 18 week of October: ‘Company users’ test 
o 24 and 3 week of October: ‘Friendly users’ test 
o 4th week of October (until end of June) and later: ‘SOCRATES?2° users’ recruitment 


e The 2" plateau is the period from February 2020 until end June 2020. New functionalities are 
added in plateau 2. 


Plateau 1 functionalities: 
e Using the static DATEX II RAZ profile. (a NDW). 
e Including improved polygons (a AMS + NDW) 
e Profile is sent via email. 
e 


End user service that contains static information; this is ‘informing only’ end service. 
(a SP) 


Plateau 2 functionalities: 

e the dynamic information (Kennedylaan) is added. This dynamic info will be shared in 
the RAZ profile. (à AMS / NDW). 

e Profile is shared via NDW official portal. 

e making the service more user friendly by adding the navigation option and/or 
personal preferences, etc. (a SP) 

e (option) the additional other static information to the RAZ profile (e.g. include bridge 
heights and allowed tonnage). 


Actual situation End of Operational period (IST End Act.4) 


Except one, all functionalities were implemented following the activity 4 design. The ‘dynamic 
information’ function was only implemented by TomTom. Because of technical challenges, Be-Mobile 
decided only to implement the static part. Also the approach towards the ‘dynamic information’ 
changed during activity 4. In this new approach two static messages alter depending on the status of 
the dynamic route. Unfortunately, because of Covid-19, there were no events in the RAI event area, 
and therefore the dynamic route was not activated. 


Furthermore, during the operational period the static information was updated due to the enlargement 
of the Amsterdam environmental zone. 


11.3 Active partners and User Stories 


Four SOCRATES?” partners are active in the Environmental Zone use case Amsterdam. 


City of Amsterdam Data provider / Road Authority 
NDW Network Monitor 

TomTom End user Service provider 
Be-Mobile End user Service provider 








User stories focus on what the partners want to be able to do. User stories should be written in one or 
two sentences and capture who the user is, what they want, and why. A simple structure for defining 
features or user stories can look something like this: Asa___, I want to achieve sothatl 
realize the following benefit of  . 
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City of Amsterdam -- Role Data provider / Road Authority 


The city of Amsterdam wants to be a good host for inhabitants and visitors alike. As a public data 
provider and road authority | want to provide reliable data about our environmental zones to road 
users. | want to achieve less environmental zone violations and an increase in usage for the dynamic 
part when the zone is deactivated. Above all, the use case should contribute to improve the air guality. 


NDW — Network Monitor 


As the national data access point in the Netherlands, | receive environmental zone data from multiple 
Dutch cities. In this case only from Amsterdam. Thereafter | enrich the data flow and make this 
information public available in standard European formats. | want to improve the availability, quality 
and accessibility of public data. 


Be-Mobile / TomTom - End user Service provider 


As a Service provider, | want to receive up-to-date and accurate data on environmental zones in 
standard formats. | want to provide most accurate information on environmental zones to my users, so 
that they experience a satisfying journey. 


11.4 Generic description of end user services 


End user service level 1: “Informing only” 


The service is to inform road users (in this case drivers of trucks, buses and coaches) who have 
planned a destination in the Environmental Zone or users who have a route through the environmental 
zone. These users are informed about the environmental zone with information on the geographical 
limitations (using a geofence). This service does not use the navigation function or vehicle 
specifications. So, the user doesn’t receive an updated route advice in case of driving through the 
Environmental Zone. However, changes on the Environmental Zone itself is included in this End user 
service. The latter is not intended during the pilot execution phase. 


v Plateau 1 functionality 


End user service level 2: “Navigation function added” 


Inform road users (trucks, buses/coaches) if their destination is in or their route is through an 
environmental zone. Informing about the existence and limitations of the (static) environmental zone 
with an option to avoid the zone. In case the dynamic environmental zone near the RAI Convention 
Centre is turned off, a route through that zone will be possible and presented if quicker. 


v Plateau 2 functionality 


End user service level 3: “User/vehicle preferences added” 


Information is only presented if the zone is applicable for user’s vehicle. A user interaction in advance 
about the type of vehicle is required for this. Information is only presented if the zone is applicable for 
user’s vehicle. A user interaction in advance about the type of vehicle is required for this. 


v Plateau 2 functionality 


End user service level 4: “other static information added” 


Additional static information is added to the RAZ profile (e.g. include bridge heights and allowed 
tonnage). This information is also shared with road users. 


v Optional plateau 2 functionality 
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12. INFORMATION ARGHITEGTURE - EZ 


12.1 Sequence diagram 


The information architecture (IA) is an elaboration of the sequence diagram originally produced for 
Activity 3. It contains processes (green) and interactions (red) between processes. The processes are 
functional and in general conducted by one stakeholder as an internal process. A process receives 
and collects data, enriches the data and produces information as a product. Information is sent via 
protocols to other processes in the architecture. 


The functional process starts with step 1 (update zone) and continues all the way to step 12 (provide 
service). 


Different data flows can be identified: 
e Step 1 to 4: distribution chain of the static information to Service providers (plateau 1: dotted 
line) 
e Step 5 to 9: triggering and activation of legal measure on the street; distribution chain of the 
dynamic information to Service providers (added in plateau 2) 
e Step 10 to 12: activation of individual info/routing (plateau 1) 


Sequence diagram - Environmental Zone 


Signs / AMS NDW Be-Mobile Road users 
sensors TomTom 


1) Update static ` 
environmental , 2) Distribute static 
zone L_ info 





r-- 
1 
| 
| 


3) Translate to 4) Distribute static 








DATEX H Le info (DATEX Il) 





















5) Trigger dynamic 
| environmental zone 2 
Logging 
dyn info 
7) Distribute dyn info Ei 
6) Rotating prism sign 
Switch off enforcement 8) Translate to 9 
) Distribute dyn 
DATEX II info (DATEX Il) 
PI at eau 2 10) Original Route 













12) Alternative Route or 
extra information 






11) Monitor traffic 
Provide end user service 





Plateau 1 ai ດ. d 


FIGURE 17. SEGUENCE DIAGRAM ENVIRONMENTAL ZONE AMSTERDAM 
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12.2 Processes and interactions 
Step 1: Update static Environmental Zone (AMS) 


The real environmental zone in Amsterdam is documented as a GeoJSON format. This is considered 
as static EZ information. The exact location of the zone is already known and detailed. Possibly the 
Environmental Zone will be changed in October 2020. So, for the duration of the project this is not an 
issue. In general changes occur not very often. 


Step 2: Distribute static info (AMS) 


At the moment the geographical data of the Environmental Zone is available on the Amsterdam 
website. Click this LINK to access the website. However, Amsterdam can deliver this data in any 
known format. 


https://data.amsterdam.nl/datasets/ot28M5SZu0h9PA/ 


The main purpose of this data is sharing the geographical zone information as static information. 
Unfortunately, this original data source is not suited for (more advanced) navigation services. Therefor 
we improved the information by adding more details to the polygons. 


Step 3: Translate to DATEX II (NDW) 


NDW incorporates the static data (polygons) from Amsterdam to DATEX II RAZ (restricted access 
Zone). The DATEX II RAZ profile is developed in cooperation with the SOCRATES?° TMex group. The 
RAZ profile can also be used for other similar purposes (e.g. bridge heights, tonnage allowance, etc). 
Exceptions are written in OpenLR. 


Step 4: Distribute static info via DATEX Il (NDW) 


The Network Monitor (NDW) publishes the static EZ information. This occurs one or two times during 
the project. The receiving partners (TomTom and Be-Mobile) configure this in their own systems. Note 
that the official NDW publication of RAZ (static and dynamic) will be part of plateau 2. For plateau 1 
the RAZ consists of static data only. Publication via email. 


Step 5: Trigger dynamic EZ (AMS) 


For some events in the RAI venue or based on congestion, the TMC can decide to reroute trucks and 
buses via an alternative route towards the highway A10. Up to 60 times a year this trigger will be 
activated. 


Step 6: Rotation Prism sign, turning off EZ (AMS) 


By activating the prism signs, this new route becomes a legal (or non-restricted) route for trucks, 
buses and coaches. The Environmental Zone becomes a bit smaller. 


Step 7: Distribute dynamic info (AMS) 


A DVM-X message is sent from Mobi-Maestro or the central Parking system. The message should be 
interpreted as an activated DVM-service (e.g. TalkingTraffic project on sharing DVM-services). 


Step 8: Translate to DATEX II RAZ (NDW) 


The Network Monitor translates this DVM-X message to a DATEX II RAZ dynamic trigger. This will not 
been done in the ‘intekentool’; instead it will be a separate created message. 
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Step 9: Distribute dynamic info via DATEX |! (NDW) 


A “small” dynamic DATEX RAZ message is sent to notify the service providers that an alternative 
route is available for trucks and buses due to congestion and or events in the RAI venue. A second 
message is sent to indicate the service should be terminated. 


Step 10: Original routes are chosen by road users 


Road users (trucks, buses/coaches) choose routes that might include this Amsterdam Environmental 
Zone. 


Step 11: Monitor traffic, calculate route (SP) 


Check RAZ change for service level 2 and higher. Internal process of service providers to provide the 
best solution for their clients (trucks, buses/coaches) based on road conditions, environmental zones 
and personal preferences. 


Step 12: Providing service / type of service (SP) 


Service providers provide services to road users (see chapter on end user services 1.3). 
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13. SYSTEM ARCHITECTURE - EZ 


13.1 System / Application overview (plateau 1) 
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FIGURE 18. SYSTEM OVERVIEW PLATEAU 1 - ENVIRONMENTAL ZONE AMSTERDAM 


13.2 System / Application overview (plateau 2) 
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13.3 Overview interfaces 


An overview of the identified interfaces is shown in the application architecture. In this picture internal 
(black) and external (orange) interfaces are shown; numbers 1, 2, 3, 4a and 4b. The internal black 
interfaces are not described in detail. Partners are responsible for own internal interfaces. Dotted lines 
represent manual processes, full lines represent automated processes. 


The external orange interfaces are shown in the table below. 


ID Partner (system/app) Information Status 
EZ AMS 1 AMS (website) -- NDW Original source for the EZ Existing source 
(manual handled) static information Existing interface 
New receiver 
EZ AMS 2 AMS (MM) -- NDW Original source and trigger for Existing source 
(DVM-X server) the EZ dynamic information Existing interface 


New receiver 
EZ AMS 3a NDW (manual handled) Result of translation to DATEX Existing source 
(plateau 1) — email RAZ — static only Existing interface 

New receiver 
EZ AMS 3 NDW (manual handled) Result of translation to DATEX Existing source 


— NDW (NCIS) RAZ (improved version) — New interface 
static only New receiver 

EZ AMS Aa NDW (NCIS) — Service Publication of static EZ info New source 
Providers — static New interface 
publication New receiver 

EZ AMS 4b NDW (NCIS) — Service Publication of dynamic EZ info New source 
Providers — dynamic New interface 
publication New receiver 
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Static RAZ publication 
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Enums 
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14. OPERATIONAL PILOT 


In Activity 3 the functional design of the use case Optimising Network Traffic Flow has been described 
and approved by the SOCRATES?° Steering Group in October 2018. In Activity 4 this functional design 
is elaborated in multiple more detailed designs. Based on this latter design the pilot is developed. 


14.1 Recruitment 


Development of end-user recruitment for ONTF and EZ in the Amsterdam pilot site. A number of 
actions and initiatives were carried out: 

- A dedicated recruitment website was built and launched in October 2019 and ongoing up- 
dated keeping pace with the recruitment activities in the pilots. The site contains an overview 
of all pilot sites and all use cases that are deployed. Visitors can register for the different 
services that become available per pilot city. For Amsterdam: 


o https//register.socrates2.org/amsterdam (Dutch and English) 
- Dedicated Facebook campaigns were prepared and executed for recruitment in Amsterdam. 
- Communication for Recruitment: 
o Factsheets/QandA for each use case in Amsterdam, language specific 
o Several video’s for recruitment and information, language/use case specific: 
= NDW - SOCRATES2.0 - YouTube 
= Navigation service with information on environmental zones in the Amsterdam 
region (youtube.com) 
= Navigatiedienst met informatie over milieu Zones in de regio Amsterdam - 
YouTube 
=  Proactief route advies in de regio Amsterdam (youtube.com) 


= Proactive route advice in the Amsterdam region. - YouTube 
o Detailed invitations in different languages to participate in the pilots published on 


partner websites and local media 
o Specific slide decks to present Amsterdam activities 
- Specific online campaigns for user recruitment by service providers 


Additionally, the Netherlands National Broadcasting Foundation has written an article and broadcasted 
a video in which the SOCRATES?” is presented as a solutions for current problems that occur when 
navigation services reroute via local roads (all in Dutch): 


Article: httos://nos.nl/op3/artikel/2325704-file-dan-rijden-we-met-z-n-allen-om-door-hetzelfde-dorp.html 


Video: https:/Awww. youtube.com/watch ?v=WZjxv6zeWUo 





14.2 Impact of Corona 


Corona had a severe impact on the functional piloting of the services developed to test the use cases. 


For the ONTF use case, traffic was nowhere near normal intensities. This resulted in far less 
congestion than before the Corona period. This, in turn, diminished the cause for necessity of 
alternative routes, since the preferred routes of users were not affected by congestion and users could 
take those routes free-flow. This led to far less enthusiasm for the recruitment of end users for this use 
case than anticipated. Additionally, the prediction engines were not calibrated on traffic flow suffering 
from Corona, resulting in less qualitative predictions as would have been the case in normal 
circumstances. 


For the Smart Destination use case, the impact was even worse, since no events were organised, 
leaving the use case with no practical circumstances to test the benefits for event public. 
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For the Road Works use case, the impact was less severe. However, this use case suffered from 
technical obstacles that proved hard to overcome. Difficulties as to establish the ground truth of where 
the actual road works took place made it difficult for proper fusion of data collected by the data 
providers. Furthermore, different profiles used by the data providers and the use of DATEX-II also did 
add to technical challenges. 


For the Environmental Zone information use case, Corona also had a severe impact. The dynamic 
nature of the use case, where the route to the RAI building is either accessible or prohibited, remained 
static, since the RAI building is used for events and those were all cancelled. 


Nevertheless, the organisational and technical set-up and execution of all use cases were tested and 
could be evaluated. This was also the case for the functional evaluation of the ONTF use case, the 
Road Works use case and the Environmental Zone information use case, although the circumstances 
were far from optimal. Additionally, a friendly-user test for the Smart Destination use case was also 
executed, providing at least some useful information for the functional evaluation of this use case. 
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